AWS ParallelCluster 3.3.0 のアップデート紹介
2022年11月2日に AWS ParallelCluster 3.3.0 がリリースされました。3.2.0 のリリースから約3か月ぶりのマイナーアップデートです。
注目のアップデート紹介
個人的な注目ポイントと、アップデートの目玉(っぽいもの)をピックアップしました。アップデート前との違いについては情報が少ないため知っている範囲で補足します。
アップデート詳細はリリースノートをご確認ください。
Release AWS ParallelCluster v3.3.0 · aws/aws-parallelcluster
ピックアップ
- ひとつのキューに複数のインスタンスタイプの割り当てをサポート
- 従来はひとつのキューに単一のインスタンスタイプしか選択できませんでした
- たとえば Queue-A に
m6i.16xlarge
,c6i.16xlarge
,r6i.16xlarge
を指定可能になりました - スポット利用時に中断確率の低いインタンスタイプを自動選択してくれる!
- デフォルトの割り当て戦略はコスト優先のため設定変更は必要
- 共有ストレージの設定をクラスター作成後に、追加・削除をサポート
- 従来はクラスター削除にクラスター管理の共有ストレージは削除されてしまいましたが残せる設定が追加されました
- Slurm の実行履歴保存用のデータベースとの連携を AWS ParallelCluster の Config でサポート
- 従来は独自に DB と連携を実装していた部分を ParallelCluster 側で吸収
- オンデマンドキャパシティ予約と、キャパシティリザーブグループをサポート
- 従来(v3.1.1 - v3.2.1)のオンデマンドキャパシティ予約の設定方法は非推奨となりました
- v3.3.0 で追加されたひとつのパテーションに複数のインスタンスタイプを登録に対応できないため
- 従来は EC2 RunInstances のパラメータを上書きする手法が取られていました
- v3.1.1 でオンデマンドキャパシティ予約(ターゲット指定)のサポートが追加されています
深堀りして詳細を追ってみましょう。
複数のインスタンスタイプ選択と割り当て戦略
目玉の追加機能なので AWS ブログで解説があります。
従来はひとつのキューに単一のインスタンスタイプしか選択できませんでした。
なにが嬉しいのか?
計算に利用するコンピュートリソースを複数あるインスタンスタイプの中から自動選択する優先順位をユーザー側で決めることができることにメリットを感じます。具体的な利用例としてスポットインスタンスで計算する場合を前提に考えてみます。
最安価なコスト優先の戦略
複数のインスタンスタイプの中からもっともスポットインスタンスの利用単価が安いのを優先してコンピュートノードを起動します。スポットインスタンスの単価は需要と供給のバランスで変動します。スポットインスタンスのコストをユーザー側で確認して今安いインスタンスタイプのあるキューを選択してジョブをサブミットする行為が必要なくなります。
デフォルトは最安価なコストを優先するの戦略になっています。
キャパシティ最適化優先の戦略
起動するインスタンス数に対して最適なキャパシティがあるインスタンスタイプを優先してスポットインスタンスを起動します。つまり、スポットインスタンスの中断率を下げることができます。
スポットインスタンスは計算中に中断が発生するかもしれないけど大幅な割り引き(最大90%オフ)を受けられるというトレードオフの関係にあります。アプリケーションが中断に備えてチェックポイントを作成できない、再実行するのに長時間かかる、だけど利用費を下げたいときはこちらの戦略がオススメです。
諸条件・設定方法
複数のインスタンスタイプをひとつのキューに登録するための必須要件をまとめておきます。
- 同じ vCPU 数であること
- Hyper-Threading 無効化時は物理コア数が同数であること
- x86_64 と arm64 の混在は不可
- Intel なら Intel、AMD なら AMD で統一
- EFA をサポートしているインスタンスタイプなら EFA を有効化にすること
インスタンスのスペック確認は以下の方法が便利です。
その他注意事後はドキュメントをご確認ください。
クラスター作成用の Config に必要な設定項目は以下のドキュメントを参考にしてください。
- Multiple instance type allocation with Slurm - AWS ParallelCluster
- Scheduling section - AWS ParallelCluster
2022/11/8追記クラスターのコンフィグを参考に載せております。
共有ストレージを残しておける
当初はクラスター作成後に共有ストレージの設定変更が不可というツラミが解消されたと思ったのですけど、ドキュメントを読んでみるとクラスター管理の共有ストレージをクラスター削除しても残しておけるDeletionPolicy
が追加されただけのようです。
以下のドキュメントを参考にしてください
EFS の例ですとFileSystemId
のアップデートポリシーはUpdate policy: If this setting is changed, the update is not allowed.
のままで変わりなく、後から EFS をマウントすることも、アンマウントすることは相変わらずできませんでした。
引き続き一時的に FSx for Lustre を使いたいときはクラスター管理の外側からヘッドノード、コンピュートノードに手を加える必要があります。
Slurm と DB の連携が手軽に
Slurm の実行履歴保存するためには以下の方法で実装していました。この実装を ParallelCluster 側で吸収してくれたようです。
クラスター作成用の Config に必要な設定項目は以下のドキュメントを参考にしてください。
ParallelCluster 側に寄せた方が運用しやすいかは別途検証してからお伝えしたいと思います。
2022/11/23追記既存の運用に影響があるのか確認しました。
おわりに
マイナーアップデートを大きな機能追加があって嬉しいですね。新機能の複数インスタンスタイプ登録も魅力的ですが、個人的には自前で実装しないといけなかった点が ParallelCluster 側で吸収してくれるようになった点が嬉しいです。ただ、実運用に耐えうるのかは検証してブログ書きます。